⚠️ No Changeset found

Latest commit: 5c6b5f1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Note to self: remove skipLibCheck from tsconfigs once this is merged https://github.com/sveltejs/kit/pull/13864/files#r2158308684

This is kinda terrifying to need; what's the rationale for doing this? There's basically no warranty for any ts-ignore remaining stable over versions.

This is kinda terrifying to need; what's the rationale for doing this? There's basically no warranty for any ts-ignore remaining stable over versions.

Using ts-ignore here really is a hack. I suppose a better solution would be something like microsoft/TypeScript#31894 where we can tell TypeScript "this type doesn't currently exist but it's okay". Basically, we just need a way to tell TypeScript we know what we're doing when it errors on types we will generate.

Indeed — I would love to come up with a better solution! If you have any suggestions I'm all ears.

Essentially the problem is this: in addition to the things exposed from @sveltejs/kit and @sveltejs/kit/*, a typical SvelteKit app will import from $app/*, which is a collection of modules that are specific to the app in question (i.e. their behaviour depends on your configuration and app structure etc). In practice this means that those modules must be bundled through Vite (so that virtual modules etc are processed), whereas @sveltejs/kit modules can be left externalized (for the server build, at least).

Since we can't expose types for $app/* in a way that TypeScript will understand via pkg.exports, we use dts-buddy to generate a bunch of declare module blocks. This works great because while the implementations of these modules are app-specific, the types are not. Or at least that was true until sveltejs/kit#13864, because now we have $app/types which is purely about exposing app-specific types. As such we can't generate declarations for $app/types, and must instead use compilerOptions.paths to point to your-project/.svelte-kit/types/index.d.ts.

I'd argue that these use cases are legitimate but I definitely realise that we are colouring outside the lines here. If there's a preferable way to accomplish all this (without a DX downgrade for our users) then I would love to know what it is!

In general, I feel like generating code directly into the user's src and using relative imports or import mapping is preferrable to tsconfig paths, rootDirs, etc. Or at least generating the code that is project specific in their project rather than publishing it to npm (so, just publish helpers).

But, I can understand that's not a shared opinion. It's just that paths, rootDirs, are being used in ways they simply were never designed to be used.

generating code directly into the user's src

That's the DX downgrade that we're trying to avoid!

generating the code that is project specific in their project rather than publishing it to npm

That's exactly what we're doing — the $app/* modules are essentially created by Vite. They're 'backed' by real modules inside the @sveltejs/kit package, which enables us to easily generate .d.ts for them, but they're not exposed via pkg.exports. And $app/types is wholly generated (specifically, in this file) and written to the .svelte-kit folder inside the project directory.